System and method for automatic financial project management

ABSTRACT

A system and method for providing project management tools to support construction, renovations, maintenance and other projects. The system automates the creation, processing and approval cycles of the numerous documents involved with each project. The system provides standardized work processes through processing templates. The system provides automated control and management of the process. The system allows project initiation and funding approval by clients throughout the corporation via a desktop browser coupled to a corporate Intranet. A software application embodying the present invention and its underlying technology are appropriate for a paper intensive area. It reduces the approval cycle of projects. It automates the creation, processing and approval cycle of documents by routing documents electronically for on-line approval.

The present invention is related to and claims priority to U.S.Provisional Patent Application No. 60/163,506 entitled AUTOMATEDFINANCIAL PROJECT MANAGEMENT SYSTEM, filed Nov. 4, 1999, the contents ofwhich are incorporated herein by reference.

FIELD OF THE INVENTION Background of the Invention

Project management, especially in the area of corporate real estateproject management, is traditionally a process which is driven by paperforms and documents. These paper documents include for example, purchaseorders, work orders, contracts, Requests for Assistance (RFA), Requestsfor Proposals (RFPs), commitments, bids, invoices, messages (genericcorrespondence), meeting announcements and minutes, project close outs,complete punch lists, project evaluations, and departmental statistics.

The processing of all of these various documents is very laborintensive, error prone and subjects the proposed projects to needlessdelays. For example, if the manager in charge of approving commitmentsis on a business trip for two weeks, a commitment requiring his or hersignature might be delayed for an additional six weeks, which in turndelays another vendor's initiation of work and so on.

Furthermore, an increase in the number of requests for new constructionor engineering projects increases the volume of documents that areprocessed by the project administration group and the accountingoperations group. This in turn requires an increase in processingcapacity through an increase in staff levels or overtime. Conversely, adecrease in volume of requests lowers the productivity of the groups, asthe staff levels are maintained to support the processing at the peakoperations volume.

SUMMARY OF THE INVENTION

The present invention was originally designed to automate the projectmanagement process for the Corporate Real Estate and FacilitiesDepartment of the assignee of the present invention. Although originallydesigned for this type of real estate and facilities department, it isreadily seen that the project management method and system of thepresent invention has wide applicability to most types of projectmanagement.

The system is a collection of process and business objects that provideproject management tools to support construction, renovations,maintenance and other projects. One primary function of the system is toautomate the creation, processing and approval cycles of the numerousdocuments involved with each project. The system and method of thepresent invention provides automation to support the following businessprocesses.

Strategic Space Planning. This function is responsible for determininghow much space is required, demographic and market analysis oflocations, and owned versus leased funding strategies.

Client Management. The system allows project initiation and fundingapproval by clients throughout the corporation via a desktop browsercoupled to the system via a corporate intranet. This concept facilitatesself-service delivery. The request component allows clients to specificrequirements for construction, renovation, relocation or officefurniture.

Project Support. The system assists the real estate department staff increating budgets and controlling how budgets are dispensed thoughpurchase orders, work orders and contracts. This includes the tablemaintenance involved in vendor authorization, workload, reassignment oftasks, security access and security registration, and changes toprocesses. Project support is provided for the administrative processessuch as administering roles and responsibilities, which includes signingauthority.

Project Management. The business objects of the system of the presentinvention assist a project manager in creating a project budget andcontrolling how that budget is dispensed through purchase orders, workorders and contracts. Invoices are processed against the commitments andare paid through an electronic accounts payable interface. Theunderlying system structure provides standardized work processes throughprocessing templates. The system provides automated control andmanagement of the process. This methodology is expandable because it istemplate based, thereby providing an environment for financial basedproject management. Additionally, Project Management includes phases ofproject initiation, predesign, schematic design, design development,construction documents, procurement, preconstruction, construction, andpost construction. The system includes project management functionalityto assist in: Tracking Project Milestones; Corporate Cost CenterAllocations for identifing how project expenses should be charged;Messages which are generic correspondence; Meeting Announcements andMinutes; Creation and approval of commitments; Approval of invoices;Project Close Outs; Complete Punch Lists; Project Evaluations; andDepartmental Statistics.

Vendor Management. The system allows direct access via the Internet toprovide extensive functionality for managing approved vendors inrelationship to specific projects. This functionality allows an approvedvendor to author Bids, Requests for Quotes (RFQs), Invoices, PunchLists, Lien Waivers and Messages. Other documents can be received andprocessed with more limited functionality. These documents includeRequest for Proposals, Contracts, Work/Purchase Orders, Change Orders,Payment Confirmations and Meeting notices. In addition, an in-box allowsfor timely communications of messages and documents.

The present invention automates the creation, processing and approvalcycles of numerous documents involved in project management. It allowsproject initiation and funding approval by clients throughout thecorporation via a desktop browser coupled to a corporate Intranet. Asoftware application embodying the present invention and its underlyingtechnology are appropriate for a paper intensive area. It reduces theapproval cycle of projects. It automates the creation, processing andapproval cycle of documents by routing documents electronically foron-line approval.

Other objects, features, and advantages of the present invention will beapparent to one skilled in the art from the following description of theinvention with reference to the accompanying drawing.

BRIEF DESCRIPTION OF THE DRAWING

For the purposes of illustrating the present invention, there is shownin the drawings a form which is presently preferred, it being understoodhowever, that the invention is not limited to the precise form shown bythe drawing in which:

FIG. 1 is an illustration of the structure of the system of the presentinvention;

FIG. 2 depicts the process flow of the present invention;

FIG. 3 illustrates the tree structure organization of project managementdata;

FIG. 4 depicts a user interface input screen for inputting a Request forAssistance;

FIG. 5 shows an approval hierarchy structure according to the presentinvention;

FIG. 6 illustrates a budget template and an example budget;

FIG. 7 depicts an On-call commitment to a vendor;

FIG. 8 shows a Purchase Order commitment;

FIG. 9 illustrates the creation of a bid package;

FIG. 10 illustrates the bid opening processing;

FIG. 11 depicts the processing of bid responses from vendors;

FIG. 12 shows the processing of a vendor invoice;

FIG. 13 illustrates a funding document generated by the system of thepresent invention;

FIG. 14 depicts the close out information available to a projectmanager;

FIG. 15 illustrates a close out ledger; and

FIG. 16 depicts a partial closeout.

DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 illustrates the system 100 of the present invention. The variousparties to the project managed by the system 100 communicate via acorporate Local Area Network (LAN) 105. Connected to the LAN 105 arevarious servers 110-120 on which reside the applications and databasessupporting the system 100. Server 115 contains the applications thatenable the clients to initiate and approve project requests and approvefunding for such projects. Work flow server 110 contains theapplications which enable the project staff to create and route projectdocuments and manage information. In a preferred embodiment, theworkplace server 110 is accessed through an icon on the staffs' workstations 120 which operates in a windows environment. The applicationscan be developed using C, Powerbuilder™, SQL, Cold Fusions™, or othersimilar software development languages and tools.

Database server 120 provides access to database 122 that contains thevarious databases housing the details of all of the projects undermanagement. In a preferred embodiment, the databases on server 110 arerelational database such as is available from the Oracle™ corporation.Illustrated in FIG. 1 is a work station 125, such as a personal computer(PC), laptop computer or other such workstations for use by projectmanagers. Clients (employees of the corporation initiating projects)access system 100 through a corporate intranet 130 and client workstations 135. Vendors access system 100 using a vendor In workstation140 connect to the corporate LAN 105 preferably through the Internet 145using a browser. The vendor workstation 140 uses a “thin” clienttechnology meaning that the majority of the software for the vendoraccess resides on LAN 105 (servers 110, 115). The firewall 150 providesall of the requisite security such as password protection,authentication and encryption (if necessary).

System 100 provides security functions based on roles, signing authorityand access rights. Security access is defined through a Role-BusinessObject-Function relationship. In addition, the ability to perform afunction on an object (e.g., a document to be approved) depends on thestate of the object. For example, as further described below, if adocument has been approved, that document can no longer be modified soas to protect the integrity of the approval.

Database 122 contains various tables that support the security functionand allow definitions such as: Roles to Person table that identifies allthe roles a person can perform; a Functions to Business Object tablethat identify all the functions and menu items available to a BusinessObject; a Tree-views to Role table that identifies all the tree views(described below) available for a role; a Functions to Role table usedto classify the functions and menu items as enabled or disabled for eachbusiness object within a role; a Function Exceptions table thatoverrides the classification for functions and menu items for eachbusiness object within a role identified at the person level (in otherwords, include or exclude a specific function in this business objectfor a person playing this role). A further table contains the state ofall of the objects being managed by the system. A history of therevisions to an object (e.g., the changes in state during the approvalprocess of a document) is maintained for auditing purposes. An object inthe present invention can have multiple documents associated therewith.For example, if the object is a bid, some of the documents associatedwith the bid could be a list of vendors (requiring approval) and acommitment (requiring its own separate approval).

FIG. 2 illustrates a overview of the project process managed by thepresent invention. The process begins with a client 160 determining thatthere is a need for the creation of a project. In the preferredembodiment the project is a construction project. The client 160initiate the project by generating a Request for Assistance (RFA). TheRequest For Assistance is typically generated by the client 160 with theassistance of a project manager 170. The process of generating an RFAwith the aid of a project manager 170 is an iterative one that involvespreparation, negotiation, performance and acceptance. The RFA containsthe nature and scope of the project, the funding available for andrequired by the project, and the schedule by which the project must becomplete. Although the RFA can be communicated by telephone call ore-mail, in a preferred embodiment of the present invention, the RFA isgenerated by the client 160 using system 100. Specifically, the clientuses its workstation 135 to connect to LAN 105 through the corporateintranet 130 (FIG. 1). The applications on web server 115 prompt theclient 160 for all of the necessary information required to complete theRFA 165. The data contained in the RFA 165 is stored in database 122 inseparate files associated with the project.

After the client 160 and the and project manager 170 have finalized theRFA, it goes through an approval process (described below) within theclient management chain 162. Once the RFA has been approved by clientmanagement 162 is it automatically forwarded to facilities management172 for approval and assignment of a project manager 170. Once theproject manager 170 has been assigned and receives the approved RFA, theproject manager 170 uses the RFA as a blueprint. As shown in loop 173,the project manager 170 can typically delegate portions of the projectto other groups (e.g., design work and its management can be delegatedto a design group within the organization). As will be further describedbelow, the project manager 170 creates bid packages, purchase orders andor contracts 175 which are used to solicit the work from vendors 180.Typically project managers 170 work with the various vendors 180 inrefining the nature and scope of the project. The project managers 170receive proposals from the vendors 180 who are bidding on the whole orpieces of the project under consideration. The communication between theproject managers 170 and the vendors can occur using the telephone ore-mail, but preferably the vendors 180 communicate with the projectmanagers using their workstations 140 through the Internet 145 andfirewall 150.

For larger projects, the result of the bidding and proposal process is acontract 175 which defines, in detail, the tasks to be preformed by thevendors 180 in completing the projects. The specific tasks to beaccomplished can be defined via a Purchase Order, a facilities agreementor a service agreement. Typically, contract 175 is a master contractwhich defines the general nature of the project as well as the generalnature of the relationship between the corporation and the vendors 180.Pursuant to the contract 175, the project manager 170 will generatespecific commitments to vendors 180 to pay for specific tasks performedby the vendors 180. The contract 175 further provides for the ability ofthe project managers 170 to issue change orders to the vendors 180 asthe scope of the project changes during the evolution of the project.

Upon completion of a task, the vendors 180 issue an invoice 185 to thecorporation. The invoice 185 can be transmitted to the corporation viatradition paper method, but preferably is transmitted in an electronicform compatible with system 100. If received in paper form, an invoice185 is scanned so that it is rendered in electronic form which can beincorporated into system 100 in database 122. The invoice 185 isreviewed by a project analyst 190 for comparison with the contract andthe commitment to the vendor 180. The invoice 185 then goes through anapproval process by the project manager 195 according to the businessrules for the project as further described below. Once approved, thepayment on the invoice goes through an accounting process 200 in whichthe payment is validated and charged against the appropriate portions ofthe contract. The payment is then remitted 205 to the vendor eitherthrough a credit to the vendor's Demand Deposit Account (DDA), via checkor via Electronic Data Interchange (EDI) remittance.

FIG. 2 has depicted the general process of how a project is initiatedand managed. The remainder of the Figures will illustrate how system 100facilitates the initiation management and closure of the projectprocess. As previously described, the workstations for managing theproject process (120, 125 in FIG. 1) operate in a windows environmentalthough any other suitable network operating system (e.g., Unix) can beemployed. System 100 includes security procedures, such as sign-onprocedures, as known by those skilled in the art. FIG. 3 illustrates atypical user interface screen 250 which will help explain the structureand functions of system 100.

Information concerning projects managed by system 100 are preferablyorganized in folders 255 by projects. In a preferred embodiment, thefolders 255 are organized in a tree structure 260. User interface 250illustrates one tree structure 260 of a particular project 270. System100 contains various predefined tree views of folders 255 which areselected using list box 265. Specifically illustrated in FIG. 3 is atree view entitled “My Projects” in list box 265. The tree view of “MyProjects” illustrated in FIG. 3 is the standard default view of system100. The “My Projects” tree view is most frequently used by projectmanagers and other support staff. Other tree views access information ina variety of ways. Other tree views include: a close out master viewthat lists all of the closed projects; a major expenditure plan viewthat lists all of the major projects; “my” major expenditure plan viewwhich lists the major projects which a particular project manager ismanaging; a personal view that is an information folder for use by theuser to store data for activities not related to specific projects; aprojects by business sector view that lists all of the projects, sortedby major business division; a project by facilities division view thatlists all projects sorted by a specific facilities department within thecorporation; a view of projects by location that lists all of theprojects sorted by location; a view of projects by project manager thatlists all of the projects sorted by the project manager managing theproject; a projects being supervised view that lists all of the projectsbeing managed by the staff of a manager within the corporation; a viewof recently approved documents that lists all of the documents that auser has approved within a predetermined period of time (e.g., twoweeks); a view of system tables that lists various categories of systemdata such as roles, user profiles, and signing authorities; and a vendorview that lists all of the vendors sorted by several categories.Although the above is not an exhausted list of all of the views capableof creation in the system 100 of the present invention, it is apreferred list of the views.

Each of the user interface screens of the system 100 include toolbars275, 280 containing icons that provide short cuts to the functionalityof system 100. In a preferred embodiment, the icons on toolbar 275 areconsistent across the user interface screens of system 100. These iconsprovide basic functionality to all screens such as a button forreturning the user to default tree view, a print button which prints thescreens, a close button which closes a screen in which the user iscurrently operating, a tile up button that returns the screen to thestandard screen format with the tree view 260 on the left hand portionof the screen and the selected item on the right hand portion of thescreen, and an exit button that is used to exit the system.

The icons on toolbar 280 change from screen to screen, depending on thefunction being performed by the user. Some of the toolbar 280 iconsillustrated in FIG. 3 include a new document icon 281 that produces anew document menu; a view notes button that produces a list of all notescreated using the notebook feature of the present invention as furtherdescribed below; a refresh button that renews and updates the tree viewafter completing an activity; a toggle tree button that toggles betweenthe tree view and a full screen view of the selected item on the righthand portion of the screen; and a create note button that activates thenotebook feature of the present invention. The icons on toolbars 275,280 and other functions of the present invention are accessed using astandard input device of the user's workstation such as a mouse. Themouse is used to click on a button to activate a specific function, toselect an item and to drag and drop items of information.

As previously described, information is preferably presented to the userin a tree view 260. The specific tree view illustrated in FIG. 3illustrates the folders 255 associated with the project 270. The userillustrated in FIG. 3 only has a single project 270, otherwise the otherprojects associated with the user would be illustrated in the tree viewarea.

Eleven folders 255 are shown as being associated with the project 270.The project directory folder 282 contains a listing of all of theproject team members as well as the project vendors. The list ispopulated from database 122 (FIG. 1) as individuals or vendors areidentified on the project. The Request For Assistance folder 284contains the approved RFA form as described above. The budget andfunding folder 286 contains all budget worksheets and funding documents.These documents include a preliminary funding document, a supplementalfunding document and surrogate funding documents. Project task folder288 contains the project tasks that are set up to assign portions of theapproved budget to specific trades (e.g., plumbing) in preparation forcreating commitments to vendors. Commitments by trade folder 290 listsall of the commitments that have been prepared for a project (includingdraft, unapproved and approved commitments). The approved commitmentsfolder 292 contains all of the approved commitments. The payments folder294 contains all approved invoices from vendors for which payment hasbeen made. The bid documents folder 296 contains all information relatedto bids and bid waivers. Each bid listed in this folder is assigned aunique number for accounting tracking purposes. Reports folder 298contains a tracking report with respect to the project which lists allcommitments and payments. This folder can also be used to store copiesof other reports. Projects attachment folder 300 contains sub-foldersfor storing scan documents or electronic files of plans, specifications,correspondence, schedules and furniture/finishes information forexample. The close out folder 302 contains partial and final close outinformation with respect to the project. Again, the above list offolders 282-302 is not exhaustive and any folders can be created whichsuit the needs of the particular project being undertaken or thecorporate system in which the system of the present invention operates.

The right hand portion of screen 250 depicts the information associatedwith the folder selected on the left hand portion of the screen. In thisparticular example, the project 270 has been selected and accordingly, aprofile 304 of the project is displayed on the right hand portion ofscreen 250. The project profile 304 contains information related to thecategory of the project, the project number, the project name, thelocation of the project, the division for which the project is beingconducted and the cost center associated with that division as well asthe current phase of the project. The project profile further includes abrief project description 306 as well as an area 308 for the projectstatus.

Although not specifically illustrated in FIG. 3, every document withinsystem 100 has its own notebook in which is recorded comments, issues orstatus information associated with the project. The notebook feature canbe activated at any time, such as while preparing a document, during theapproval process, or even after final approval. Notes can be savedgenerally in three different categories. A first category is a commentwhich includes general notes for the facility staff. A second categoryof notes is the status of the project which contains on going projectstatus information. This status information from the notebook isdisplayed in the status area 308 in the project profile area. The finalgeneral category of notes contains specific notes to be published toother members of the team such as the clients. The published notes areavailable to the clients as previously described through the corporateintranet 130.

As previously described, the project management process initiated by aRequest for Assistance (RFA). FIG. 4 illustrates an initial userinterface screen 350 for creating an RFA. The RFA is prepared eitherdirectly by a requestor or by a coordinator within the business unitrequiring the project. There are generally two types of informationrequired on an RFA, requestor information 352 and information related tothe project requested 354. The input screen 350 allows the user to inputall of the required information into an electronic RFA form. In apreferred embodiment, the electronic form is used for projects over apredetermined dollar amount (e.g., $10,000). If the project total isless than the predetermined amount, the user can e-mail the project andrequestor information to the facility staff. The facility staff can thenprepare an internal RFA on behalf of the requester so that the requestcan be inputted and managed within the system 100 of the presentinvention.

Once the RFA has been completed, the user saves the document and clickson a button (not shown) to send the RFA for approval. This action bringsup a client hierarchy screen 360 illustrated in FIG. 5. This screenrepresents one of the unique features of the present invention. Onscreen 360, the user is able to identify the proper personnel requiredto approve the RFA. In the specific example depicted in FIG. 5, threeseparate approvals are required for the RFA. The first approval is abusiness unit manager 362, the second approval by a business unitcontroller 364 and the final approval by a business executive 366.Different rules are capable of being set in the database 122 of system100 such that depending on the scope of the project (typically the totaldollar amount) the number of approvals will change. For example, forlarger projects (e.g., above $100,000) a business unit executive 366will be required to approve the RFA. In area 368, the user is able toselect the actual person who is fulfilling the role required forapproval. The database of system 100 contains all of the relevantinformation with respect to each person in each business unit that canfulfill each role (e.g., name, e-mail address, title, etc.). The usercan select the appropriate person from a drop down menu by selecting thedown arrow on each box in area 368.

Once the appropriate people have been selected for the approval roleswith respect to the RFA, the user clicks on the submit button 370. Thisaction automatically forwards the electronic RFA to the personfulfilling the role of the first level of approval required for the RFA.A notice of the pending RFA requiring approval is added to the workflowlist of pending tasks of the approver. This workflow list is accessed bythe approver using button 375. When activated, this button provides alist of all of the documents requiring the persons' approval. Theapprover is then able to click on the notice which will bring up theactual electronic RFA document for review by the approver. After thereview is complete, the reviewer is able to type any notes into acomment area of the RFA document and select one of several actions. Ifthe approver approves the RFA, the electronic RFA is sent to the nextindividual in the approval hierarchy. System 100 enables electronicsignatures as is well known to those skilled in the art. The approvercan also return the RFA for clarifications to the previous approver orto the requester. Such an action should be accompanied by the approverincluding notes in the comment area which further define theclarifications required. The approver can also disapprove the RFA whichsends the form directly back to the requestor or client coordinator.Again, if the RFA is disapproved, the approver should include notes inthe comment area including reasons for the disapproval. Finally, theapprover can discontinue the review of the RFA and come back to completethe review at a later time. In this action, the notice of the pendingRFA will remain in the approver's work list. If the RFA is approved bythe final approver in the client hierarchy, the form is automaticallyrouted to a dispatcher in the project management staff. At this point,the approved RFA is assigned a project number and a project manager.

The automatic approval process of the present invention has severaldistinct advantages. First, the process is instantaneous. Once adocument has been submitted for approval, notice of the receipt of thedocument for approval is immediately sent to the approver and thedocument is immediately available for review. This is in sharp contrastto the prior art method of approval in which documents typically werererouted using interoffice mail. Apart from the delay associated withsuch a mail system, documents were often lost or misplaced. Tracking thestatus of approvals using the present invention is as simple as clickingon a button on the user's screen. The prior art required someone toconduct a series of phone calls, e-mails and personal visits to theapprovers. Another advantage of the approval hierarchy of the presentinvention is that it recognized the corporate reality that people oftenchange jobs, responsibilities, and locations. If such a change occurs,the database 122 of system 100 is easily modified to reflect the change.For example, if someone having the role of an approver is promoted andanother person takes over the role, the database can be easily modifiedto replace the promoted person with the successor. Any subsequentapprovals will then be automatically forwarded to the successor.Similarly, if someone having a role is on a temporary leave or absence,any task assigned to that person (e.g., approvals) can be easily andtemporarily reassigned to a substitute person.

Additional functionality provided to the clients of system 100 is theability to view a list of RFAs for its business unit by clicking button378. This button will bring up a window containing all of the RFAs ofthe business unit. The list will include the project name, the dateprepared, the status of the RFA and the status of the funding of theproject. In a similar manner, a client is able to view a list of all ofthe finding documents by clicking on button 380. The finding list willdisplay all of the funding documents for projects on which the user isinvolved. Once a list is displayed in the system 100 of the presentinvention, the user is able to view the actual documents associated withthe item by selecting the particular item.

After the approved RFA has been received by the project staff, one ofthe first tasks for the project staff is to create a budget and fundingdocuments for the project. FIG. 6 illustrates a user input screen 400for creating budgets and funding documents. In a preferred embodiment,budgets are created using predefined templates. Area 402 allows the userto view a list of all of the budget templates available within system100. These templates can either be global (general formats available toall personnel) or private (i.e., templates that the user has personallycreated for his or her own use). Once a template is selected, thetemplate is displayed in area 403 on the left hand portion of screen400. In the preferred construction embodiment of the present invention,the templates contain three levels of project information, includingindividual trades (e.g., lighting fixtures), trade categories (e.g.,electrical) and summary categories (e.g., construction, 404 in FIG. 6).The templates in area 403 can be viewed in the standard view asillustrated in FIG. 6, or a tree view as previously described, thatshows summary categories in expandable folders.

Once the template is displayed, the user is able to create the uniquebudget for the project in area 406 by dragging and dropping the itemsfrom the template area 403 into the budget area 406. For each item inthe budget, the user is required to input the unit 408, quantity 410 andprice 412. Once these items 408-412 have been input by the user, system100 automatically calculates the cost of the item 414. Additionally,system 100 allocates the cost as a capital item 416 or an expense item418. System 100 additionally calculates an allowed contingency amount420 which can be set in the system as a percentage of the cost (e.g.,10% of the capital cost). The user is able to increase or decrease thiscontingency amount in area 422.

If the creation of the budget document lasts longer than the usersession, the user can save the budget as a worksheet and come back at alater time and complete the budget. Once the budget has been finalized,it is saved in a final form. The budget is then used to create a fundingdocument that requires approval. The budget is a very complex anddetailed document(s) that potentially includes hundreds of trades,capital items, expense items, etc. Rather than have the client andfacilities management approve the very detailed budget, the system ofthe present invention generates a funding document for approval. Anexample of a funding document is depicted in FIG. 13. The fundingdocument of FIG. 13 was generated by a template accessing data from thedatabase containing the budget. It is appreciated that any template canbe used to generate any type or form of funding document desired. Asseen in this Figure, the funding document summarizes the capital itemsfor the project 700 as well as the expense items 705. These summaries700, 705 provide the approvers with an overview of the total spendingfor the project without the complexity of the details of the entirebudget. Further shown in FIG. 13 are the names of the approvers of thefunding document as well as the dates of the approval. The fundingdocument indicates approval by both the facilities department 710 aswell as the management of the business unit 715.

As previously described with the approval process for an RFA, theproject staff member submits the funding document for approval which isautomatically forwarded to the facilities hierarchy for approval. Again,the first person in the facilities hierarchy receives a notice in his orher work list regarding the funding document to be approved. The sameautomatic forwarding of approved documents is follows as described abovewith respect to an RFA. Again, if at any level of the approval processthe reviewer denies approval or requests further clarification, thefunding document is automatically returned to the previous approver withnotes in the comments section providing reasons for the disapproval orthe required clarification. Once the funding document has been approvedby all levels of the facilities hierarchy, it is automatically forwardedto the client hierarchy for its approval. In a preferred embodiment, theclient business unit has a similar level hierarchy for approvals,depending on the scope and size of the project. The same approvalprocess is repeated within the client business unit including automaticforwarding of approved funding documents. Once the funding document hasreceived final approval from the client hierarchy, it is automaticallyforwarded to the assigned project manager who acknowledges the approvedfunding document. The funds are now available for commitments and theprocess of managing the project begins.

With the approved RFA and budget in place, the project manager is ableto begin the actual project management. This process starts with theproject manager generating commitments to vendors for various aspects ofthe projects. In the preferred construction embodiment of the presentinvention, the commitments include: architectural/engineering on calls;Purchase Orders; bids; bid waivers; contracts; change orders; and workorders. Architectural/engineering on-calls are commitments for on-callconsultant services which typically result in the generation of apurchase order. A Purchase Order is a commitment for goods, materials,equipment or services, typically up to a predetermined dollar amount(e.g., $25,000). In the preferred embodiment, commitments over thepredetermined amount (e.g., $25,000), require competitive bids. Again,these bids result in purchase orders for goods, materials and equipmentor contracts for the provision of services. Alternatively, forcommitments over the predetermined dollar amount, biding can be waivedpursuant to a special bid waiver approval process. Work orders arecommitments made against a master contract with a vendor for certainservices of any dollar amount and for other trade services up to apredetermined amount (e.g., $10,000). Change orders are amendments topreviously approved purchase orders or contracts, either increasing ordecreasing the dollar amount. The change order results in a revisedpurchase order or a revised contract.

The commitments are created against the previously approved funding andbegin with the creation of a project task that assigns a portion of theapproved budget to a specific trade. In order to create a project taskfor a commitment, the project manager selects the new document icon (281in FIG. 3) to create the task. Activation of this icon 281 displays adocument selection menu which includes the various documents which theproject manager is able to create. A selection exists for each of theabove-identified types of commitments (e.g., an on-call commitment). Byselecting one of the items, the project manager is required to completea description of the project task including the trade, the protocol forthe commitment (e.g., source, bid, waived bid, negotiated, nationalcontract), the type of commitment (e.g., purchase order, contract, workorder) the tax status of the commitment (e.g., taxable, nontaxable) anda detailed description of the scope of work to perform pursuant to thecommitment.

The project manager is further required to complete a trade code detailssection. All of the trade codes that are contained within the approvedbudget are displayed (e.g., electrical). The project manager is able todrag and drop the applicable trades from the project budget to the tradecode portion of the project task. The project manager then types in thedollar amount for each applicable trade for the commitment. Once theproject manager has completed the above, the project manager saves theproject task and is then able to generate the actual commitment.

FIG. 7 illustrates a complete commitment request 450 for anarchitectural/engineering on-call. In creating this commitment 450, theproject manager was prompted to enter information related to the project455, information related to the consultant (vendor) 460, the scope ofthe job and the square footage affected and the fees associatedtherewith 465, as well as a summary of the funding and financialcommitments 470, both with respect to this particular commitments andthe project in total. Many of the items found on this on-call commitmentwere obtained from pull down menus (not shown) such as the consultant.Other items such as the cost center to be changed for work performed areprovided by system 100 as a default once the project number is inputtedby the project manager. Once the on-call commitment has been completedby the project manager, the project manager submits the commitment forapproval to the project staff. As previously described, the approvalprocess is automatic, with each level of approval being able to approvethe document, disapprove the document or return the document forclarification.

In addition to the electronic commitment, system 100 provides theproject manager with the capability of scanning in additional documentsthat are associated with the commitment or creating any attachment suchas spreadsheets, JPEG files, drawings. In the preferred embodiment, suchattachments are created using Object Linking and Embedding (OLE)compliant software. Additional documents attached to a commitment mayinclude proposals from the consultant or vendor. These attachments areavailable for review by the approvers at their work stations byselecting a view menu and selecting the attachments choice on the viewmenu (not shown).

Once an on-call commitment request has received final approval, system100 automatically generates a purchase order number and notifies theproject manager (electronically) of the purchase order number. A hardcopy of the purchase order is issued by the project staff to the vendor.Preferably, the vendor is also able to obtain an electronic copy of thepurchase order through the Internet interface previously described withrespect to FIG. 1. The purchase order contains all of the basicinformation contained in the on-call commitment request as illustratedin FIG. 7. In the preferred embodiment, when the vendor opens theelectronic purchase order (or other document such as a contract or achange order), the vendor is presented with a set of appropriatefunctions. For example, for contracts, a command button will be providedto Agree to the terms or Not Agree with an opportunity to comment orcreate addendum. The Agree function invokes an electronic signatureprocess. Some functionality may not be available based on the stage of aparticular process. For example, invoices cannot be created until a workdocument has been accepted.

In the preferred embodiment, records relating to a vendor remainavailable in system 100 for a period of at least one year following thejob's completion. Documents the vendor can author include Bids, RFQs,Invoices, Punch Lists, Lien Waivers and Messages. Documents the vendorcan receive and process with limited functionality are Request forProposals, Contracts, Work/Purchase Orders, Change Orders, PaymentConfirmations and Meeting notices. In this preferred embodiment, thevendor is only allowed to view documents they authored or documentsintended for them. The ability to delete documents are limited from avendor's perspective and may only be allowed depending on the state of adocument. This will provide for a document draft feature prior toposting to the workflow.

The generation of a project task for purchase orders is the same asdescribed above with respect to on-call commitments. FIG. 8 illustratesa request for a purchase order commitment 475 generated by system 100 ofthe present invention. The project profile information 455 is the sameas described above with respect to the on-call commitment. Thecommitment information 480 includes the trade involved, the type ofcommitment (a purchase order in this example) and the protocol for thecommitment. The vendor information 485 describes the vendor to which thePurchase Order is to be issued. Again, this information can be input bythe project manager using drag and drop methods previously describedfrom a master list of vendors for the selected trade. The selection ofvendors can either by from all of the vendors contained in the system orfrom vendors with which the corporation has a master contract. The costassociated with the purchase order is entered in area 490 and thesummary of the financial commitments is again listed in area 470. Aswith the on-call commitment described above, the project manager is ableto scan non-electronic documents into the system for attachment to thepurchase order. Once the purchase order request has been saved, it canbe submitted for approval and proceeds through the approval hierarchy aspreviously described. Upon final approval, the purchase order is issuedto the vendor with notification being made to the project managerelectronically.

A project task for a bid is again created as described above. Once theproject task has been created, the project manager is then able tocreate a bid package 500 as illustrated in FIG. 9. System 100automatically assigns a bid number 502 to the bid package as well asassigning the bid status 504 of “initialization”. As previouslydescribed, a bid is an object that can have many documents associatedtherewith. Each document can have a separate approval process asdescribed above. There is not necessarily a one to one relationshipbetween documents and the object with which they are associated. Thetrade 506 is obtained by the system from the information provided by theproject manager in the creation of the project task. The project managerthen inputs the invitation and bid due dates 508 and 510 as required bythe project. The contract type 512 is selected by the project managerfrom a pull down menu (not shown). The project manager further inputsany special instruction in area 514. The bid package total 518 isautomatically calculated by the system as the sum of the tasks 520. Thetasks 520 are initially populated by system 100 from the entries inputthe project manager when creating the project task. The project managercan add additional tasks in area 520 that he or she desires to be bidupon. The task can relate to the same project number or be associatedwith different projects, The price options 522 defaults to a base price,but the project manager can select alternative pricing options from apull down menu (not shown). The documents supporting the bid are listedin area 524 and include such documents as architectural or engineeringdrawings as well as equipment specifications.

Once the bid package has been saved. The project manger is provided witha bid package vendor selection screen that allows the project manger tochoose the vendors from which bids will be requested. Again, the projectmanager is able to select the vendors from a list complied from thedatabase 122 in system 100. Once the project manager has finishedselecting the vendors from which bids will be requested, the list issaved and submitted for automatic approval as described above. Once thelist of proposed bidders has been approved, the bid package is sent toeach of the bidders in hard copy form and preferably in electronic form.

Prior to the bid due date, the bidders submit their bid proposals inresponse to the bid package. Due to legal concerns, it its preferablethat the bids be opened and witnessed by two and preferably threewitnesses. FIG. 10 illustrates an input screen 550 used for conductingthe bid opening. As illustrated in this Figure, three witnesses 552 areprovided. System 100 requires these witnesses 552 to input their IDs andpasswords when conducting the bid opening. As each bid is open, theinformation from each vendor is input into area 554. The vendor name andthe price options are defaulted by the system 100 from the approvedproposed bidder list previously described. The amount 556 is obtainedfrom the vendors bid and is input into the system by the project staff.Additionally, the actual bid documents are scanned into system 100 andlinked as attachment to the project. Once all of the bids from theselected bidders have been entered, the bid responses on screen 550 issaved and the bid opening is officially closed. The project manager isnow able to perform an evaluation of the bids.

In performing the bid evaluation, the project manager selects the biddocuments folder (296 in FIG. 3) to view the various bids. The biddocuments folder contains all of the bids associated with the selectedproject. Selecting a modify button (not shown) activates a bidevaluation screen 560 as illustrated in FIG. 1l. As seen in screen 560,each of the bidding vendors is displayed. The project manager is able toenter a qualified price 562 which is either the bid amount submitted bythe vendor during the bidding process or an adjusted amount due toclarifications with the vendor after the bid has been opened. Theproject manager is additionally able to enter any comments on thepricing in area 564 with respect to each of the vendors. The projectmanger is then required to rank the vendors in area 566 and provide areason for selecting a particular vendor in area 568. If additiondocuments have been submitted by the vendors, they can be scanned in andattached to the data for project as well as other attachment such asdrawings. Once the project manager has completed his or her ranking 556,the bid evaluation is saved and submitted for approval. The automaticapproval process proceeds as described above with respect to theapproval hierarchy.

The above has described a process for creating and approving three typesof commitments, namely architecture/engineering on calls, purchaseorders and bids. Similar processes are performed for the creation andapproval of bid waivers, work orders and change orders. These processesshall not be specifically described herein, those skilled in the artappreciated how such processes are accomplished.

After the commitments have been made to the various vendors and the workhas been completed, the vendors submitted invoices for the services andmaterials provided pursuant to the commitments. In a preferredembodiment of the present invention, the invoices are electronicallytransmitted from a vendor workstation 140 (FIG. 1) through the Internet145 and the firewall 150 for receipt by system 100. Alternatively, paperinvoices may be submitted, scanned and the data entered into the systemeither manually or through drag and drop methods. The project managerreviews the invoice data contained in system 100 against the scannedcopy and makes any necessary adjustments in the payment amount,retainage, freight/delivery or tax, based on the actual goods orservices provided.

FIG. 12 illustrates an example of an invoice data entry screen 600.After an invoice has been received, the purchase order number 602, theinvoice number 604 and the invoice date 606 are entered. System 100,using the purchase order number 602, automatically fills in thecommitment information 608 as well as the vendor information 610. Theamount of the invoice including the material amount, the freight amountand the taxable amount are entered in area 612. Once the data has beenentered on invoice data entry screen 600, the data is saved andsubmitted for approval. The invoice approval process follows theapproval hierarchy described above with respect to the other documentsgenerated by the system. In a preferred embodiment, if the invoiceamount does not exceed the commitment amount, the project manager alonecan approve the invoice. If the invoice amount does exceed thecommitment amount, the project manager can prepare a change order. Thechange order requires approval through the hierarchy and the issuance ofa revised purchase order reflecting the adjusted commitment amount. Oncethe invoice has been approved, the payment can be made to the vendoreither through the issuance as by check, crediting of the vendors demanddeposit account, or through other EDI means.

One further advantage of the present invention is the automatic natureof the tracking of the accounting information. A general rule is thatany required accounting information (e.g., the business unit to whichitems will be charged) is captured by the system as soon as possible andthereafter carried through throughout the project. For example, once theclient identifies the business unit to be charged, this identificationis automatically carried into the templates for the project, commitmentsand invoices. All documents created from these templates will thereforeautomatically carry the identification of the business unit to becharged.

As briefly described above, one of the features of the present inventionis the ability to automate the close out process. The process of closingout a project has historically been an arduous and manually intensiveprocess. As previously described, the preferred embodiment of thepresent invention relates to construction projects, and the close outprocess will be described in terms of this embodiment. The closeoutprocedures of the present invention automate the financial transactionsassociated with the following two processes: handling of a project's CIP(construction-in-progress) account balance; and the final closing of aproject.

The CIP account is a holding account that captures a constructionproject's capital expenditures. At the end of the project, the balancein the CIP account is passed to a fixed asset (F/A) account fordepreciation. Until the asset has been thus transferred, it cannot bedepreciated. After the balance is passed to a fixed account it startsdepreciating thus creating depreciation expenses for portion of thecorporation that is benefitting from the project. There is no hardrequirement for the construction project to be 100% complete in order tocommence depreciation. Depreciation can start with the payment of thefirst invoice with respect to the project. Typically, financialaccounting rules governing construction projects employ an 80% thresholdfor commencing depreciation (i.e., 80% of the project must be completebefore depreciation is started). The specifics of a project mightrequire for the depreciation to be started both before or after an 80%threshold is reached.

As previously described, many of the processes of the method and systemof the present invention are driven by the documents related to theproject. The final closing of a project in the system of the presentinvention is a system controlled procedure that starts with automaticexamination of various states of the project documents. As a result ofthis thorough examination, the system produces an on-line diagnosticswhich highlights all inconsistencies detected by the process. Theproblems are categorized and displayed for the project manager.

The system performs several types functions related to close outs,including a partial close out, a full close out, abort a close out andcancel a close out. A partial closeout is a type of closeout that isdone when there is a need to move a portion of CIP balance to a F/Aaccount. On larger projects, either in terms of funds and or the periodof time for completing the entire project, having multiple partialcloseouts is a very useful function practical. A full closeout is a typeof closeout that is performed by the project manager only once. Aftersuccessful completion of full closeout the project is closed to anyfurther activity (including commitments and payments). A Cancel closeoutis a type of closeout that is performed by the project manager in a casewhere a project was initiated in the system of the present inventionbut, before any commitments were issued to the vendors or any invoiceswere paid, the decision was made to stop it. An abort closeout is a typeof closeout that is performed by a project manager when the clientrequested to stop the project after the funding was approved,commitments were issued and/or invoices were paid.

A trigger built in the system initiates the first partial closeout for aproject when the payment of a particular invoice meets the 80%threshold. The 80% threshold is with respect to the entire project. Thistrigger for a partial close out can be set to occur with respect to anyevent that is kept track of in the system. For example if there areseveral phases of a project, the trigger can cause a partial closeout atthe completion of a particular phase. The trigger initiates a workflowprocess gets started that opens a closeout session. The systemautomatically links all of the paid invoices for the project to thecloseout session created by the trigger. The system also generates asubstantial number (sometimes hundreds) of financial transactions thatwill be sent to the General Ledger (G/L).

The work flow process sends the generated transactions to an analyst inthe financial area. After reviewing the transactions, the analystapproves the session. This single automated procedure alone replaces asubstantial manual effort (document collection, data entry, datavalidation, etc.,) which would take weeks or even months to complete.The financial analyst can request that the system start a partialcloseout if needed. In the preferred embodiment, there is nosystem-imposed limit on the number of partial closeouts that can beprocessed by the system.

FIG. 14 illustrates the close out information that the system makesavailable to the project manager. As previously described with respectto FIG. 3, the tree structure of folders in the project manager'sdirectory includes a close out folder 800. Opening the close out folderbrings up the screen 802 seen in the left hand portion of FIG. 14. Closeout screen 802 contains six tabs 805-830 for viewing further informationwith respect to the status of the various close outs with respect to aproject.

As illustrated in screen 802 in FIG. 14, the Financial Summary tab 805displays a summary of the overall financial status of the project.Information in area 835 provides identification of the project, whilethe information in area 840 summarized the actual financials. Thefinancial information in area 840 includes the budget for the project,the amount of the budget that has been committed, the amount of thecommitments that have been paid, the percentage of the budget that hasbeen paid, the retainage held and the retainage paid. On this singlesummary screen 802, the project manager is quickly able to obtain asummary of the progress, from the financial point of view, of theproject.

Each of the other tabs, commitments 810, unapproved budget 815,unapproved commitments 820, change orders 825 and invoices 830respectively bring up screen that detail the status of the subjectmatter related to the items associated with the tab. For example, thecommitments tab 820 brings up a screen (not shown) that shows in detailall of the commitments that were created in the system. For eachcommitment, the screen shows the vendor to which the commitment hasmade, the category (e.g., construction, move) the amount of thecommitment, the amount paid to date and the remaining balance of thecommitment. The remainder of the tabs 810-830 bring up similar screensthat list all of the items associated with the tab.

The folders Closeout Ledger 850 and Partial 860 in the project manager'stree directory contain further information related to the closeoutstatus. The closeout ledger folder 850 bring up a screen 900 asillustrated in FIG. 15. This ledger screen 900 includes a summary are905 and a detailed area 910. Within the detailed area 910, there is anentry for each of the closeouts associated with the project. In theparticular example depicted in this Figure, only a single partialcloseout has been executed with respect to the project. FIG. 16illustrates the details associated with a partial closeout. Area 950lists the project information and the project details are listed in area955. Area 960 contains the details as to the G/L accounts to which theitems in the partial closeout were assigned. Area 970 details thedifferent G/L accounts to which items were posted as well as thedepreciation schedule that is assigned to the items.

When a project has been completed, the project manager initiates a finalcloseout. Again, the full level of automation associated with thepartial closeout as described above is applied to the full close out. Incontrast to a partial closeout though, additional tests are performed tomake sure that no unfinished business associated with the project isleft unattended. For example, one test is performed to expose any unpaidinvoices. Another test is performed to identify any commitment that isnot fully paid. A further test is performed to identify any credit froma third party (e.g. a real estate) due to the project that is notcollected. And so on. A full diagnostic of the state of the project ispresented to the project manager in a manner of seconds and a list ofactions required is fully identified. In the prior art manual process,this undertaking would have required days if not weeks to complete.

To close projects that were canceled before they were started and thosethat were stopped after they were started, two other types of closeoutprocessing are performed as previously described, Cancel closeouts andAbort closeouts. Various tests are performed by the system to help theproject manager to handle these exceptional conditions correctly.

Although the present invention has been described in relation toparticular embodiments thereof, many other variations and other useswill be apparent to those skilled in the art. It is preferred,therefore, that the present invention be limited not by the specificdisclosure herein, but only by the appended claims.

1-67. (canceled)
 68. A construction payment management systemcomprising: a server that stores an application, the applicationreceiving information from a participant in a construction project; anda database server connected to the server, the database server storingthe information of the participant, the application accessing theinformation of the participant in order to transfer to the participant apayment associated with the construction project.
 69. The constructionpayment management system of claim 68, further comprising a notificationmodule.
 70. The construction payment management system claim 69, whereinthe notification module is an inbox for timely communications ofmessages and documents to the participant.
 71. The construction paymentmanagement system of claim 68, wherein the participant is a vendor. 72.The construction payment management system of claim 71, wherein thevendor is a construction entity.
 73. The construction payment managementsystem of claim 68, wherein the information is an invoice relating tothe construction project.
 74. The construction payment management systemof claim 68, further comprising a web server, wherein the participantaccesses the construction project through the web server.
 75. Theconstruction payment management system of claim 68, wherein theconstruction project is associated with a document collection and thedocument collection is maintained in the database server.
 76. Theconstruction payment management system of claim 75, wherein the documentcollection has a plurality of documents, each of the plurality ofdocuments in the document collection being associated with a respectiveelectronic notebook, the documents in the document collection beingelectronic documents, each electronic notebook including associatedcategories, for each electronic notebook the categories providedincluding: a comment category that includes general notes; a statuscategory that includes a status of the construction project ; and apublished notes category, the method including publishing notes in thepublished notes category to a team working on the construction project.77. The construction payment management system of claim 68, wherein thereceived information is encrypted during transmission.
 78. Theconstruction payment management system of claim 68, wherein theconstruction project being a contract and the document collectionincluding contract documents.
 79. The construction payment managementsystem of claim 68, wherein the construction project is engineeringrelated.
 80. The construction payment management system of claim 68,wherein the construction project is architectural related.
 81. A methodof managing a construction payment process implemented by a computer,the method comprising: receiving by an application an invoice and a lienwaiver from a participant in a construction project; approving theinvoice; and transferring monetary funds to the participant.
 82. Themethod of claim 81, further wherein transferring monetary funds to theparticipant is achieved by one of the following: giving a credit to theparticipant's Demand Deposit Account (DDA), issuing a check, or usingElectronic Data Interchange (EDI) remittance.
 83. The method of claim81, wherein the construction project is associated with a documentcollection and the document collection is maintained in the databaseserver.
 84. The method of claim 83, wherein the document collection hasa plurality of documents, each of the plurality of documents in thedocument collection being associated with a respective electronicnotebook, the documents in the document collection being electronicdocuments, each electronic notebook including associated categories, foreach electronic notebook the categories provided including: a commentcategory that includes general notes; a status category that includes astatus of the construction project ; and a published notes category, themethod including publishing notes in the published notes category to ateam working on the construction project.
 85. The method of claim 84,wherein approving the invoice further comprising: identifying approversthat comprises an approval hierarchy, the approval hierarchy being aseries of approvers; automatically forwarding a notice requestingapproval of at least one electronic document, in the documentcollection, from a previous approver to a successive one of theapprovers upon approval of the at least one electronic document by theprevious approver in the approval hierarchy.
 86. The method of claim 81,wherein the construction project being a contract and the documentcollection including contract documents.
 87. The method of claim 81,wherein the construction project is engineering related.
 88. The methodof claim 81, wherein the construction project is architectural related.89. A construction payment management system comprising: a server thatstores an application, the application receiving information from aparticipant in a construction project, wherein the information isencrypted during transmission; an inbox allowing timely communication ofmessages and documents to the participant; a web server, wherein theparticipant accesses the construction project through the web server;and a database server connected to the server, the database serverstoring the information of the participant, the application accessingthe information of the participant in order to transfer to theparticipant a payment associated with the construction project, whereinthe construction project is associated with a document collection andthe document collection is maintained in the database server, whereinthe document collection has a plurality of documents, each of theplurality of documents in the document collection being associated witha respective electronic notebook, the documents in the documentcollection being electronic documents, each electronic notebookincluding associated categories, for each electronic notebook thecategories provided including: a comment category that includes generalnotes; a status category that includes a status of the constructionproject ; and a published notes category, the method includingpublishing notes in the published notes category to a team working onthe construction project.